Iterative Process

1. Conceptualise
2. Analysis
3. Design
4. Implementation
5. Testing
6. Deployment

Waterfall Process
The main idea with this method of management is you do not move to stages before each is completed.
Consider starting a website project, whose "bootstrap" do you use?. While deciding all other aspects wait.
Time constraints are important with this method of management.

The Iterative Process means that as you develop software you go through the entire process repeatively
and try to enhance your knowledge of the requirements.
The basic concept is that when the requirements are defined, a design is started.
During the design phase, issues arise that require a modification and enhancement of the requirements.
When you have a start on the design, you prototype parts of your project.
During this prototyping phase, issues arise that affect the design and possibly even the requirements.
This way the development of a project occurs as it naturally would in practice.
The suggested repetitive sequence is as follows:

Conceptualise

Analysis

Design

Implementation

Testing

Deployment

Contents

At the beginning of the project there is a visionary who is responsible for the project.
This may be the person with the main idea of the person given the responsibility for ensuring that
the project adheres to the vision of the idea built by a group of people.
In other design methods, this is often known as the mission statement.

For example, Java Services for the Web uses:
"Electronic Trading over the Internet in a changing market".

This is a very high level definition of the project plan.

The analysis phase is the development of the vision into specific requirements.
It covers the understanding of the project scope in terms of a problem to be solved.
Frequently this involves writing down how the application will be used and how it is to perform.
Typically the results of the analysis phase are as follows:

Use cases - steps that show how the system will be used

Interaction diagrams - how different objects on the application will work together

System analysis - Hardware documentation

Application analysis - The customer requirements specific to this application

Operational constraints - various performance issues, concurrent users, response times

Costs and Planning - Scheduling, milestones and costs

Contents

Analysis focuses on understanding the problem.
Design focuses on how to solve the problem.
Design is the process of taking the requirements and generating a solution that can be developed into software.

The result of the design process is a design document.
A design document defines the following key points:

the static class design

the dynamic class design

the architectural mechanism design

The static class design defines the classes, their methods and properties.
The dynamic class design defines the interactivity between the classes.
The architectural mechanism design defines such properties of your application such as persistence and how the system will be distributed.
Contents

Implementation happens after the first pass of the design phase is in place.
This is the point where you understand how you will solve the development problem.
With the iterative model you should remember that prototypes may have been created to help with the analysis and design phases.
It may be that these prototypes become the basis of the implementation phase or even that they are abandoned,
apart obviously from the lessons learned when creating these prototypes.

There are two forms of testing:

1. blackbox
2. whitebox

They are not restricted to the Quality Assurance department alone.

It may be that the project actually creates testing scripts that are to be followed
as well as seeking sign off by the various parties in the project that the test have been performed.

Blackbox testing is where you randomly execute the program, going from one piece of functionality to another.
Peroidically, the tester verifies that the application is still performing correctly.

Whitebox testing is where a given set of inputs to test are created and compared to a known output result.
Test scripts clearly work much better with whitebox testing.

It should be remembered that the product is often released before it is finished.
You would expect the bare minimum of functionality to satisfy the user need would be present.
This is often called a baseline and most of the parties know that further functionality will be added to future products.
This approach clearly allows the customer to provide feedback for the subsequent versions.
Contents

The Waterfall method places distinct boundries between the control topics.

This classic approach requires that the customer signs off on the requirements;
agrees that the functionality in the requirements document is
exactly everything required in the final product.

After this analysis stage the requirements document is passed to the design who then designs the entire system.
The design document is then passed onto the implementers who create the program based on this document.
The program is then handed to Quality Assurance for testing and release.

The problem with this model is that it is natural for mistakes to enter at all stages of the product.
Therefore mistakes get magnified as you traverse further down the waterfall.

It can be even worse than that, the true vision of the product is rarely obvious at the requirements stage
but with this model there is no opportunity for anybody to change their mind
once the process has moved to the next stage.
Contents